home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc0722.txt < prev    next >
Text File  |  1994-01-21  |  6KB  |  162 lines

  1. Network Working Group                                       Jack Haverty  (MIT)
  2. Request for Comments: 722                                             Sept 1976
  3. NIC #36806
  4.  
  5.  
  6. I. ABSTRACT
  7.  
  8.  
  9.      This paper addresses some issues concerned with the
  10. design of distributed services.  In particular, it is
  11. concerned with the characteristics of the interactions,
  12. between programs which support some service at various
  13. network sites.  The ideas presented are derived mainly from
  14. experience with various service protocols [Reference 1]
  15. on the ARPANET.
  16.  
  17.      A model is developed of interactions between programs.
  18. Salient features of this model which promote and simplify
  19. the construction of reliable, responsive services are
  20. identified.  These dualities are motivated by problems
  21. experienced with various ARPANET protocols and in the design
  22. and maintenance of programs which use these protocols in the
  23. performance of some service.
  24.  
  25.      Using this model as a template, the general
  26. architecture of one possible interaction protocol is
  27. presented.  This mechanism provides a foundation on which
  28. protocols would be constructed for particular services,
  29. simplifying the process of creating services which are easy
  30. to implement and maintain, and appear reliable and
  31. responsive to the customer.  This presentation is meant to
  32. serve as an introduction to a specific instance of such a
  33. protocol, called the RRP, which is defined in one of the
  34. references.
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.                                 -1-
  61. II. OVERVIEW AND TERMINOLOGY
  62.  
  63.  
  64.      This paper considers the interaction of two programs
  65. which support some network service.  It develops a model of
  66. the interactions of a class of such applications, and
  67. includes some thoughts on desirable goals and
  68. characteristics of implementations.  The model is derived
  69. from a proposal [Reference 2] for mail-handling
  70. systems.  Terminology, as introduced, is highlighted by
  71. capitalization.
  72.  
  73.      Many uses of computer networks involve communication
  74. directly between programs, without human intervention or
  75. monitoring.  Some examples would include an advanced
  76. mail-handling system, or any kind of multi-site data base
  77. manager.
  78.  
  79.      Such programs will be termed SERVERs.  They are the
  80. users of some mechanism which provides the needed
  81. communication and synchronization.  The particular facility
  82. which the servers implement will be termed a SERVICE.
  83. Servers for any particular service may be written in several
  84. languages, operate in various system environments on
  85. different kinds of computers.  The entity which utilizes the
  86. service will be termed the CUSTOMER.
  87.  
  88.      Servers interact during ENCOUNTERs, which are the
  89. periods when two servers are in communication.  An encounter
  90. begins when one server establishes a CHANNEL, a
  91. bidirectional communication link with another server.  The
  92. interaction between servers is effected by the exchange of
  93. information over the channel.  The conventions used in such
  94. an exchange are defined by the PROTOCOLs for the
  95. interaction.
  96.  
  97.      The theme of this paper is a model for a particular
  98. class of process interactions which may be used as a basis
  99. for many possible services, where the interactions are
  100. fairly simple.  Services which fit in this category interact
  101. in a manner which can be modeled by a REQUEST-REPLY
  102. DISCIPLINE, which is defined herein.
  103.  
  104.      A set of guidelines and goals is developed, which
  105. address issues relevant to ease or implementation and
  106. reliability of operation of servers.  These guidelines may
  107. be used to assist in the formulation of protocols specific
  108. to appropriate services.
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.                                 -2-
  118.      Additionally, the guidelines presented may be used as a
  119. basis for a general process interaction protocol, by
  120. extracting the primitives and operational concepts which
  121. would be common to a protocol constructed for virtually any
  122. such service.
  123.  
  124.      From these ideas, a protocol which provides a
  125. foundation can be constructed, to be extended for particular
  126. services by adding primitives specific to each.  The RRP
  127. [Reference 4] is one such possible protocol.  It
  128. provides basic primitives to control the interaction between
  129. servers, and a mechanism for extending the primitives to
  130. include service-specific operations.
  131.  
  132.      The discussion here is primarily intended to explain
  133. the basis for the design of the RRP, and to present some
  134. general issues of design of services.
  135.  
  136.  
  137. III. THE REQUEST-REPLY DISCIPLINE
  138.  
  139.  
  140.      The class of services relevant to this discussion are
  141. those whose interactions could be performed in the following
  142. manner.
  143.  
  144.      Two servers have established a channel by some external
  145. means.  A single interaction between servers begins with one
  146. server, called the REQUESTER, issuing a request.  The server
  147. receiving that request, the RESPONDER, issues a REPLY.  The
  148. requester interprets the reply sequence to determine whether
  149. the request was successful, failed, or partially failed, and
  150. takes appropriate action.  Such a sequence of events is
  151. termed an EXCHANGE.  This is analogous to a subroutine call
  152. in a simple single-processor operating system.
  153.  
  154.      This model is termed a REQUEST-REPLY DISCIPLINE of
  155. program interaction.  It should be noted that this is only a
  156. model of program behavior, and does not necessarily exclude
  157. services which require, for example, some measure of
  158. pipelining of requests for efficiency in long-delay
  159. situation;.  In fact, most network services would require
  160. such measures, put their interactions can still be reduced
  161. to the request-rep
  162.